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Foreword 


ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies 
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO 
technical committees. Each member body interested in a subject for which a technical committee has been 
established has the right to be represented on that committee. International organizations, governmental and 
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the 
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization. 
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2. 

The main task of technical committees is to prepare International Standards. Draft International Standards 
adopted by the technical committees are circulated to the member bodies for voting. Publication as an 
International Standard requires approval by at least 75 % of the member bodies casting a vote. 


Attention is drawn to the possibility that some of the elements of this document may be the subject of patent 
rights. ISO shall not be held responsible for identifying any or all such patent rights. 


ISO 13374-2 was prepared by Technical Committee ISO/TC 108, Mechanical vibration and shock, 
Subcommittee SC 5, Condition monitoring and diagnostics of machines. 


ISO 13374 consists of the following parts, under the general title Condition monitoring and diagnostics of 
machines — Data processing, communication, and presentation: 


— Part 1: General guidelines 
— Part 2: Data processing 
— Part 3: Communication 


— Part 4: Presentation 
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Condition monitoring and diagnostics of machines — Data 
processing, communication, and presentation — Part 2: Data 
processing 


1 Scope 


The various computer software systems written for condition monitoring and diagnostics (CM&D) of machines 
that are currently in use cannot easily exchange data or operate in a plug-and-play fashion without an 
extensive integration effort. This makes it difficult to integrate systems and provide a unified view of the 
condition of machinery to users. The intent of ISO 13374 Parts 1 through 4 is to provide the basic 
requirements for open CM&D software architectures which will allow CM&D information to be processed, 
communicated, and displayed by various software packages without platform-specific or hardware-specific 
protocols. 


To adequately describe all data processing requirements, modern software design requires both an 
information model and a processing model. This document details both the information model requirements 
and the processing model requirements to which an open CM&D data processing architecture shall conform. 
Parts 3 and 4 of the ISO 13374 series will address specific software specification requirements for 
communication and presentation respectively. 


2 Normative references 
The following referenced document is indispensable for the application of this document: 


ISO 13374-1:2003, Condition monitoring and diagnostics of machines — Data Processing, Communication, 
and Presentation — Part One: General Guidelines 


3 CM&D information architecture requirements 


3.1 Overview 


An information architecture describes all the data objects and their properties (or attributes), property data 
types, data object relationships, reference data, and data documents for a given system or application. An 
open CM&D information architecture specification shall describe their content for each of the five layers shown 
in Figure 1. 


—_ 
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Data Document Definitions Layer 5 
Reference Data Library Layer 4 


Implementation Data Model Layer 3 
Conceptual Information Model Layer 2 
Semantic Definitions Layer 1 


Figure 1 — CM&D Information Architecture Layers 


3.2. Semantic definition requirements 


To ease understanding among various parties utilizing the information architecture, an open CM&D 
information architecture specification shall provide a set of semantic definitions for each major data object in 
the system. Non-formal description terminology, such as English language definitions of the data objects, 
may be used. Formal descriptions utilizing ontological schemas, such as the proposed Resource Description 
Format (RDF) of the World Wide Web Consortium (W3C), may also be utilized. 


3.3 Conceptual information model requirements 


A conceptual information model is an integrated definition of all the primary data objects relevant to CM&D, 
along with their major properties (also called "attributes"), property data types, object interrelationships, and 
object or relationship constraints. An open CM&D information architecture specification shall provide a non- 
proprietary conceptual information model, sometimes referred to as a "schema", which is independent of how 
the data is physically stored or accessed. This conceptual information schema is a blueprint of the location of 
various data elements which facilitates system integration and data integrity. Using a conceptual schema, an 
implementation data model can be verified. 


The Unified Modelling Language (UML) has emerged as the software industry's dominant modelling language 
and includes a standardized Class Diagram representation for information modelling. The Object 
Management Group (OMG) adopted UML as its standard modelling language. As an approved Publicly 
Available Specification (PAS) submitter to the International Organization for Standardization (ISO), the OMG 
is proposing the UML specification for international standardization. 


3.4 Implementation data model requirements 


Based on the conceptual information model, an implementation data model provides the exact representation 
of data elements which shall be transferred or stored. An open CM&D information architecture specification 
shall provide an open implementation data model which conforms to its conceptual data model. 


The open CM&D implementation data model shall allow for the integration of many sources of machinery 
information, support peer-to-peer databases, allow user-defined lookup entries, and utilize standardized 
timestamps and engineering units. The schema should support unique enterprise, site, and database or data 
source identifiers to differentiate data taken at different physical locations. The schema should also support 
unique, system-wide identifiers for plant segments containing machinery (service segment locations) in a 
parent-child hierarchy. Also the schema should support unique asset-specific identifier to allow individual 
component monitoring and tracking in a parts hierarchy. 
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The basic framework of storing enterprise, site, site database, process or machine segment information (such 
as physical orientation, drive type, mounting type, and shaft coupling type), asset nameplate data (including 
entries such as rated speed, rated power, make and model, and bearing or other component information), 
measurement locations, data measurement sources, transducers, transducer orientation, engineering units, 
signal processing post-scaling types, ordered lists, and alarms should be specified in the schema. At a data 
level, the schema should support formats for communicating historical single-valued numeric data, Fast- 
Fourier Transform (FFT) spectra data, constant percentage band (CPB) spectra, time waveforms, sample- 
based test data, thermographic images, and binary large objects. The schema should support a date/time 
notation that references back to a specific instance in time, using the Gregorian (Common Era, or CE) 
calendar, with a lexical representation based upon the ISO 8601 standard referenced to Universal 
Coordinated Time (UTC) and also stores the local time zone offset. 


This specification can be specified using various schema definitions. The file description schema format has 
been used for years in the scientific programming community. It maps the format for ASCII or binary data files, 
which can be exported from a computer system or imported into a computer system. A complete record 
format description is published which specifies the data fields contained in the file, their exact location in 
relation to the other data fields, whether the fields are in ASCII or binary format, and the exact data format — 
real floating point, integer, character, varying character string — of each field. 


The relational information schema format is the definition language for relational database management 
systems. The relational method is analogous to a blue-print drawing which defines the various "room names" 
or (tables) where data will be stored, the data "contents" or (columns) in the rooms, each data column's exact 
data format (scientific floating point, integer, varying character string, etc.), whether or not a data column can 
be empty or not (not null) and each data row's unique "key" (primary key) which uniquely identifies it. A table 
can be related to another table by including a "reference" (foreign key) to it. 


An Extensible Markup Language (XML) schema definition (XSD) is a recommended definition language. XML 
is a project of the World Wide Web Consortium (W3C), and the development of the specification is being 
supervised by their XML Working Group. XML is a public format written in the Standard Generalized Markup 
Language (SGML), the international standard (ISO 8879:1986 "’) for defining descriptions of the structures of 
different types of electronic documents. The version 1.0 specification was accepted by the W3C as a 
Recommendation on February 10, 1998. On May 3, 2001, the W3C issued XML Schema as a W3C 
Recommendation. XML Schemas define shared markup vocabularies, the structure of XML documents, 
which use those vocabularies, and provide hooks to associate semantics with them. By bringing datatypes to 
XML, XML Schemas increases XML's utility to the developers of data interchange systems. XML Schemas 
allow the author to determine which parts of a document may be validated, or identify parts of a document 
where a schema may apply. Further, as XML Schema are XML documents themselves, they may be 
managed by XML authoring tools. 


Regardless of which information schema format is chosen the data model shall define a minimum set of data 
elements that should be included in the schema for compliance. In addition, a list of optional elements shall 
be included. 


3.5 Reference data library requirements 


To effectively utilize an implementation data model, standard entries for various look-ups need to be stored in 
a reference data library. An open CM&D information architecture specification shall provide an open 
reference data library which conforms to its implementation data model. The specification should support 
populating and maintaining industry-standard taxonomies and codes for the reference data and allow both 
suppliers and end-users to add industry-specific and customer-specific entries to the library using database- 
unique entries. The specification shall also support the creation of a standard set of reference codes in 
various languages as required. 


The reference data library specifies all code tables for segment (machine/component) type codes, asset type 
codes, measurement location type codes, engineering unit type codes, sampling test codes, 
diagnostic/prognostic event codes, health codes, failure codes, and root cause codes. The library also houses 
engineering unit codes, measurement location type codes, and mounting orientation codes. 


© ISO 2004 — All rights reserved 3 


ISO/CD 13374-2 


3.6 Data document definition requirements 


An open CM&D information architecture specification shall also specify the format for the publication of a data 
document. The specification allows the reference data library to be read or written in a standardized way and 
supports applications which need data import/export capability. 


Specifications which utilize the file description schema format as their implementation data model will most 
likely utilize the same specification for the publication of an ASCII or binary data document. The complete 
record format description shall be published, which specifies the data fields contained in the file, their exact 
location in relation to the other data fields, whether the fields are in ASCII or binary format, and the exact data 
format — real floating point, integer, character, varying character string — of each field. 


Specifications which utilize the XML schema format as their implementation data model will most likely utilize 
the same format for the publication of an XML data document. XML schema provides the definition of the 
XML document and XML parsers and validation tools can verify the syntax of the document's content. 


3.7 Compliant specifications 


MIMOSA is a non-profit trade association which develops and encourages adoption of open information 
standards for Operations and Maintenance. MIMOSA publishes an open CM&D specification which is 
compliant with the above requirements. The specification is known as the MIMOSA Open Systems 
Architecture for Enterprise Application Integration (OSA-EAI™) specification. Appendix A describes this 
specification in more detail. 


4 CM&D processing architecture requirements 


4.1 Overview 


A processing architecture describes all the interactions or transactions which are between modules internal to 
the software system itself, external from end-user interactions, or external from other software system 
interactions. An open CM&D processing architecture specification shall utilize the processing architecture 
shown in Figure 2. This architecture is defined as blocks of data processing functionality. After each block in 
the system has been properly configured, the basic data is converted into digital form in Data Acquisition (DA) 
and is processed in various ways as it is transformed into actionable information, resulting in Advisory 
Generation (AG). As the processing progresses from data acquisition to advisory generation, data from 
preceding blocks needs to be transferred to subsequent blocks and additional information acquired from or 
sent to external systems. Similarly, as the data evolves into information, both standard technical displays and 
graphical presentation formats are required. In many applications, data archiving is required in order to 
maintain a history of the output of each block. Each block is responsible for managing data quality, as required, 
and flagging its output with the appropriate assessment. Output should be identified as good, bad, or 
undetermined. 
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Figure 2 — Data processing block diagram 
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4.2 Data Acquisition (DA) blocks 


As detailed in Figure 3, the data acquisition block has been generalized to represent the software module that 
provides system access to digitized sensor or transducer data. The data acquisition module may represent a 
specialized data acquisition module that has analog feeds from legacy sensors, or it may collect and 
consolidate sensor signals from a data bus. Alternately, it might represent the software interface to a smart 
sensor. The data acquisition module is basically a server of calibrated digitised sensor data records. 


Data Acquisition (DA) Block 


Transforms the output of a transducer or test to a scaled digital representation. 


Analog Digital Manual 
Input Input Input 
——<—=—= DA Control 
Triggers 
(for operating state 
DA Output <n notification) 
Buffer / DA Processing 
Archive * Gather digital and manual input data ams DA Synchronization 
* Gather analog input data and perform analog Signals 
to digital conversion (for multi-channel 
simultaneous data 
acquisition) 
Geum DA Configuration 
(DA measurement 
location data, DA 
parameters, 
DA Output DA Configuration etc.) 
(digitized data with timestamp & 
data quality) 


Figure 3 — Data Acquisition block 


The output of all DA blocks shall contain the following: 

— digitized data 

— timestamp of data collection with UTC reference and local time zone 
Examples of the digitized data include: 

— floating point values for scalar data 

— magnitude and time series for dynamic data 

— thermal radiation data with digitised image for thermographic data 


— _ sample test results for lubricating fluid/air/water sample data 
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4.3. Data Manipulation (DM) blocks 


As detailed in Figure 4, the data manipulation block processes the digital data from the DA block to convert it 
to a desired form which characterizes specific descriptors (features) of interest in the machine condition 
monitoring and diagnostic process. Often the functionality within this layer consists of some signal processing 
algorithms. 


Data Manipulation (DM) Block 


Calculates descriptors (features) from sampled sensor data, other descriptors, 
or the output of computations. The computation may be characterized as an 
input-output mapping. 


DA Input DM Input 


{| 


DM Processing 


* Gather current data from DA modules 
and other DM blocks 


Retrieve DA or other DM historical data 


DA Output ===> 


Buffer / 
Archive * Perform signal transformation (e.g., === DM Configuration 
FFT, and digital filtering) ee ay 
* Perform synchronous and non- algorithm 
DM Output <=") synchronous averaging parameters, etc.) 
Buffer / + Perform computations 
Archive 


* Perform feature extraction 


DM Output DM Configuration 
(descriptor data with timestamp & 
data quality) 


Figure 4 — Data Manipulation block 


This block may contain speciality processing functions such as Fast Fourier Transforms, wavelets or simple 
average values over a time interval. 


Examples of the descriptor outputs of the DM block include: 
— Extracted feature 
— Conversion from time domain to frequency domain and vice versa 
— Calculated, non-interpretative values 
— Virtual sensor (differential pressure from inlet & outlet pressure) 
— Integrating acceleration to velocity 
— Filtering 
— Normalization 


— Time series including sample rate 
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4.4 State Detection (SD) blocks 


As shown in Figure 5, the primary function of the state detection (sometimes referred to as “state awareness”) 
is to compare DM and/or DA outputs against expected baseline profile values or operational limits and output 
enumerated state indicators (e.g. level low, level normal, level high, "alert", "alarm", etc). The state detection 
module may also generate alerts based on defined operational limits or baselines. When appropriate data is 
available, the state detection block should generate assessments based on operational context, sensitive to 


current operational state or operational environment. 


State Detection (SD) Block 


Categorizes data and generates descriptors for a measurement location, 
component, or system as normal or abnormal, including the degree of abnormality 
in the associated operational context. Also known as “state awareness”. 


DA Input DM Input SD Input 


1 4 


SD Processing 
DM/ DA Output ==> ° Gather current data from DM, DA, and 
Buffer / other SD blocks 
Archive * Retrieve DM, DA, and other SD 
historical data 
* Retrieve operational load data 


<= SD Operational Data 
(load, etc. from external 
system) 


——<—<= SD Configuration 


SD Output <== «Calculate current values of (SD location/ 
pares condition/statistical indicators ade 
rchive ‘ 
Evaluate state SD algorithm 
parameters, etc.) 
SD Output SD Configuration 


(current enumerated state indicator, threshold 
boundary alerts, and statistical analysis data 
with timestamp & data quality) 


Figure 5 — State Detection block 


Typically, this block of processing provides data which will contribute to a diagnosis in the health assessment 
block. The SD block may make use of current and historical DA and DM inputs to evaluate the current state. 
It may provide data manipulation and sensor module control signals such as acquisition scheduling 


commands, data triggers and processing instructions. 
Examples of outputs of the SD block include: 
— Enumerated state indicator 
— Threshold boundary alerts 
— Severity of threshold boundary deviation above/below 
— Rate of change alert 
— Anomalies 


— Statistical analysis 
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4.5 Health Assessment (HA) blocks 


As shown in Figure 6, the health assessment block is an information block which utilizes expertise from a 
human or automated agent to determine the current health of the equipment and diagnose existing fault 
conditions. It determines the state of health and potential failures by fusing the outputs of the DA, DM, SD, 
and other HA blocks. 


Health Assessment (HA) Block 


Performs agent-specific assessments of a component's or system’s current health 
state with the associated diagnoses of discovered abnormal states in the associated 
operational context. May also include evidence and explanation information. 
DA DM sD HA 
Input Input Input Input 


oe 


HA Processing 
¢ Gather data from SD, DM, DA, 


SD/ DM/DA =| — and other HA blocks <= _ HA Operational Data 
Output Buffer / * Retrieve SD, DM, DA, and other (load, etc. from external 
Archive HA historical data system) 


Retrieve operational data 


Estimate current health grade HA Configuration 


: z F (HA agent data, 
fia eae Diagnose failures HA component/system data, 
uffer : Generate evidence, and HA algorithm parameters, etc.) 
Archive explanation 


HA Output HA Evidence & HA Configuration 


(health grade & Explanation 
diagnosed failures) 


Figure 6 — Health Assessment block 


An output of this block includes the component/system's current health grade and diagnosed failures with 
associated likelinood probability. A calculation of the current Risk Priority Number (RPN) may also be 
performed. Modelling of ambiguity groups and multiple hypotheses may be included in the output data 
structures. The HA block may also output an explanation detailing the evidence for a diagnosis or health 
grade. 
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4.6 Prognostic Assessment (PA) blocks 


As shown in Figure 7, the primary function of the prognostic assessment block is to project the future state of 
the monitored equipment, taking into account projected future operational usage. This block determines the 
future state of health and future failure modes by combining the relevant outputs of the DA, DM, SD, and other 
HA blocks and applying a prognostic algorithm or model based on supplied projected operational utilization. 
To aid the algorithm or model, the HA block may also retrieve account historical failure data and operational 
history, along with projected failure rates related to operational utilization. 


Prognostic Assessment (PA) Block 


Performs agent-specific assessments of a component's or system's future health 
state with the associated predicted abnormal states and remaining life for a projected 
operational context. May also include evidence and explanation information. 
DA DM sD HA PA 
Input Input Input Input Input 


| 


PA Processing 
¢ Gather data from HA, SD, DM, 
DA, and other PA blocks ; 
HA/ SD / —- a § <4q——=—== PA Operational Data 
DM/DA * Retrieve HA, SD, DM, DA, and (projected future load, etc. 
other PA historical data from external system) 
Output Buffer / f : 
Archive . Retrieve projected future 
operational data qe PA Configuration 
PA Output <=> ¢ Estimate future health grade (PA agent data, 
Buffer / * Prognose failures PA component/system data, 
Archive * Prognose remaining life PA algorithm parameters, etc.) 
* Generate evidence & explanation 


PA Output PAEvidence & PA Configuration 
(future health grade, Explanation 

future failures, 

remaining life) 


Figure 7 — Prognostic Assessment block 


The prognostics layer may report health grade at a future time, or may estimate the remaining life of an asset 
given its projected usage profile. Assessments of future health or remaining life may also have an associated 
prognosis of the projected fault condition. A calculation of the future Risk Priority Number (RPN) may also be 
performed. An output of this block includes the future component/system's future health grade and future 
failure events with associated likelihood probability. Modelling of ambiguity groups and multiple hypotheses 
may be included in the output data structures. The PA block may also output an explanation detailing the 
evidence for a proposed failure event or health grade. 
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4.7 Advisory Generation (AG) blocks 


As detailed in Figure 8, the primary function of advisory generation data processing block is to integrate 
information from DA, DM, SD, HA, PA, other AG blocks, and external constraints (safety, environmental, 
budgetary, etc.) and provide optimized recommended actions and alternatives to applicable personnel or 
external systems. Recommendations may include prioritised operational and maintenance actions and 
capability forecast assessments., or modifying operational profiles to allow mission completion. The decision 
support module needs to take into account operational history (including usage and maintenance), current and 
future mission profiles, high-level unit objectives, and resource constraints. 


Advisory Generation (AG) Block 


Integrates information (including safety, environmental, operational goals, 
financial incentives, etc.) to generate advisories to operations & maintenance 
and respond to capability forecast assessment requests. 
DA DM SD HA PA_ AG 
Input Input Input Input Input Input 


| 


AG Processing <= AG Operational Data 
* Gather data from PA, HA, SD, (projected future load & 
PA/HA/ SD / =——,- DM, DA, and other AG blocks operational goals from 
DM/DA * Retrieve PA, HA, SD, DM, DA, external system) 
Output Buffer / and other AG historical data <q External Constraints 
Archive * Retrieve projected future (safety, environmental, 
operational goal data budgetary, etc. from 
AG Output<—=> - Retrieve external constraints external system) 
Buffer / * Generate O&M advisories <== AG Configuration 
Archive * Generate evidence & explanation (AG agent data, 
AG component/system data, 


AG algorithm parameters, etc.’ 


AG Output AG Evidence & AG Configuration 
(O&M advisories & Explanation 
capability forecast 

assessments) 


Figure 8 — Advisory Generation block 


Maintenance advisories from this block should detail future maintenance work required, which may include the 
verification of monitoring data or the performance of additional monitoring. The structure of these advisories 
should be put into a "work request" format for external maintenance work management systems. Based on 
this request, maintenance work management systems can schedule work in advance and locate spare parts 
and tools required for these jobs. 


Operational advisories from this block can be immediate in nature, such as the current notification of operators 
of alerts and resulting action steps. Other production-related advisories can be more strategic, such as 
sending a notice to a production planning system about the high risk of failure on a production line due to a 
soon-to-fail critical piece of equipment. 


Capability forecast assessments from this block provide the results for requests of the likelihood of 
accomplishing a specific mission or production run. These assessments are critical to production forecasting 
systems when evaluating whether or not to accept certain missions/orders and where to assign the work 
based on asset optimization principles. 
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4.8 Block configuration 


Each data processing block requires configuration information, some of which may be static data and other 
parameters may be changed dynamically by the system during operation. 


As an example, the following is a sample of the configuration of the Data Acquisition block: 
— Measurement Location Description (Measurement Location table) 
— Orientation & Relative position 
— Location Description 
— Monitoring Intervals — Dynamic vs. Static 
— On-line Continuous 
— On-line Polled 
— Default polling rate 
— Default parameters 
— Triggered vs. Non-triggered 
— Set points 
— Deadband 
— Asynchronous vs. synchronous 
— Transducer Information 
— Response curve 
— Measurement confidence 
— Transducer electronic data sheet (TEDS) information 
— Calibration 
— Channels 


— _ Single or Multiple channel collection 


4.9 External systems 


Retrieval of previous work histories from the maintenance system and previous operational data 
(starts/stops/loads) from a process data historian is important in the assessment of machinery health. After a 
health assessment is made, the maintenance action to be taken can range from increasing the frequency of 
inspection, to repair or replacement of the damaged machinery or component. The affect on operations may 
be an adjustment of operating procedures or a request to shutdown the equipment immediately. This need for 
rapid communication to maintenance and operational system requires software interfaces to maintenance 
management systems and operational control systems. These interfaces are useful in order to communicate 
recommended actions in the form of maintenance work requests and operational change requests. 
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4.10 Data archiving 


Data archiving is an important feature during all processing of a machine condition monitoring program. 
Previous data trends can be analysed for statistical relevance. Previous advisories should be audited for 
accuracy and root cause information added upon its discovery. 


4.11 Technical displays 


To facilitate analysis by qualified personnel, relevant technical displays showing data from each block is 
necessary. These displays will be expanded in detail in ISO 13374 Part 4. These displays should provide the 
analyst with the data required to identify, confirm, or understand an abnormal state. 


4.12 Information presentation 


Information from the HA, PA, and AG blocks are displayed by this processing block. These displays will be 
expanded in detail in ISO 13374 Part 4. It is important that the data be converted to a form that clearly 
represents the information necessary to make corrective action decisions. In some cases, the user will need 
the ability to drill down into the SD, DM, and DA technical displays when anomalies are reported. 


4.13 Compliant specifications 


An open CM&D processing architecture specification shall utilize the processing architecture as described 
above. Specifications shall specify a processing data model/schema and an application programming 
interface (API) interface description which meets ISO/IEC 14750:1999 for the processing blocks which they 
expose. This will allow various data processing blocks from various suppliers to be integrated into a complete, 
functional system. MIMOSA publishes an open CM&D specification which is compliant with the above 
requirements. The specification is known as the MIMOSA Open Systems Architecture for Condition Based 
Maintenance (OSA-CBM™) specification. Appendix A describes this specification in more detail. 


Figure 9 shows how these blocks can interact with each other to form a complete integrated system. The hub 
of the wheel structure represents the communications medium between the modules, which may be 
accomplished using popular communication and middleware technologies. Therefore, the modules do not 
need to reside on the same machine but may reside anywhere on a local or worldwide network. Open 
systems architecture design enables the integration of improved prognostic capability within new or existing 
system designs, allowing maximum flexibility for future upgrades to the system. 
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Figure 9 — Data processing Flow Within a Standard Architecture 


A module may implement functionality of one or more data processing blocks from the processing architecture. 
For example, module A from Figure 10 implements the functionality of the State Detection block. Module B, on 
the other hand, implements functionality of two blocks: Health Assessment and Prognostic Assessment. A 
module may implement one or more block APIs. Modules from other layers implement one or more layer APIs. 
For instance, module D from Figure 10 implements the functionality of two blocks: Data Manipulation and 
State Detection. In this case, the module provides information about manipulated data and computed 
conditions. 
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Figure 10 — Example of Compliant Modules 


An example of a complete OSA-CBM compliant system is shown in Figure 11. The system has the largest 
number of Data Acquisition (DA) blocks which feed into more complex blocks until finally one Advisory 
Generation (AG) block sends its maintenance and operations decision support to an external user display. 
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Figure 11 — Example of an OSA-CBM Compliant Modular System 
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Annex A 
(informative) 


Compliant specifications 


MIMOSA's OSA-EAI™ CM&D Information Architecture Specification 


MIMOSA is a non-profit trade association, which develops and encourages adoption of open information 
standards for operations and maintenance. MIMOSA is composed of industrial asset management system 
providers and industrial asset system end-users who develop open information integration specifications for 
managing physical assets. 


MIMOSA’s Open Systems Architecture for Enterprise Application Integration (OSA-EAI) specification 
(available for download at www.mimosa.org) is compliant as a CM&D information architecture specification 
with ISO 13374 Parts 1 & 2 and facilitates the integration of asset management and CM&D information 
throughout multi-site enterprises. _MIMOSA’s OSA-EAI system specifications offer advantages for 
maintenance and reliability users as well as technology developers and suppliers. 


For users, the adoption of MIMOSA OSA-EAI specifications facilitates the integration of asset management 
information, provides a freedom to choose from a broader selection of software applications, and saves 
money by reducing integration and software maintenance costs. 

For technology suppliers, the adoption of MIMOSA OSA-EAI specifications stimulates and broadens the 
market, allows concentration of resources on core high-value activity rather than low value platform and 
custom interface requirements, and provides an overall reduction in development costs. 


The OSA-EAI Version 3.0 architecture is shown in Figure A.1 below: 


MIMOSA OSA-EAI Architecture: May 2004 


Support Levels 
1 
2 


[| Production 
[ Beta 
el Draft 
[] Design Phase 


[] OPC Foundation Specification 


Figure A.1 — MIMOSA OSA-EAI Architecture Diagram 
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OSA-EAI Terminology Dictionary 

To ease understanding among all parties using MIMOSA's OSA-EAI specification, MIMOSA provides a 
standard set of terminology in the OSA-EAI Terminology Dictionary. This provides the basic semantic 
descriptions used throughout the OSA-EAI specifications. 


Common Conceptual Object Model (CCOM) 

The Common Conceptual Object Model (CCOM) provides the basic conceptual model basis for OSA-EAI. 
Software designers familiar with class diagrams in Unified Modelling Language can utilize this model to 
understand the basic classes, major attributes, and relationships between classes in OSA-EAI. CCOM V3.0 is 
available in PDF document form and Visio (VSD) format. 


Common Relational Information Schema (CRIS) 

MIMOSA's Common Relational Information Schema (CRIS) provides a common implementation schema 
which allows information from many systems to be communicated and integrated. The schema is in a 
relational format, commonly used in most database systems. Each table in CRIS is assigned a unique table 
reference number. CRIS V3.0 is published in PDF document form, Word document form (DOC), and XML 
Schema (XSD) form. 

Data sources which house asset information are not required to be physically re-designed to match CRIS, but 
must be able to translate their information into CRIS tables and columns. In order to ease this translation and 
for MIMOSA implementers who desire to implement a physical CRIS database, MIMOSA provides an 
ORACLE and Microsoft SQLServer table creation scripts. 


CCOMI/CRIS contain standard enterprise, site, functional segment, asset, and agent identification 
nomenclature. An enterprise is the corporate level of an organization, or the top organizational structure of a 
non-profit or military body. An enterprise is composed of many sites. The enterprise uniquely identifies the 
sites it manages. The enterprise ID is a globally-unique identifier and is defined as a 4-byte, non-negative 
integer assigned by MIMOSA. Normally, MIMOSA will issue one enterprise ID per corporation/organization. 
For some organizations, multiple enterprise IDs may be requested. In addition, MIMOSA will also assign the 
enterprise with a globally-unique, alpha-numeric user tag identifier value. This can be used in conjunction with 
the user tag identifier in the site table to form a globally unique text string. A representative from the 
registration authority for an organization should e-mail the MIMOSA _ Enterprise Registrar at 
info@mimosa.org with the name of the organization, requested enterprise User Tag Identifier, contact name, 
title, phone number, and e-mail address. The MIMOSA Enterprise Registrar will then assign the enterprise ID 
and enterprise User Tag Identifier and return the assigned non-negative integer and associated 8-byte string 
to the point of contact. 


A “site” is what an enterprise defines as an entity which can be decomposed into segments and which 
generates new assets, agents, databases, and measurement locations. A given enterprise can contain many 
sites. A site can contain many segments. For facility applications, the “site” normally represents a building. 
For industrial applications, this entity normally represents a physical plant. For fleet applications, this entity 
normally represents a “mobile platform’, which could be an aircraft carrier or a tank. Each enterprise must 
uniquely identify its sites by a 4-byte, non-negative site ID integer to allow multiple sites to utilize the MIMOSA 
standards without fear of duplication when combining information at the enterprise level. The site ID is a 4- 
byte, non-negative integer. Each enterprise is free to assign site IDs in the range from 0 — 4,294967,295 (Hex 
“00000000” — “FFFFFFFF”). Once this assignment has been made, the number should not be changed. 


Because CCOM and CRIS are designed for multi-site collaborative asset lifecycle management, nearly all 
table in CRIS (except MIMOSA-owned reference tables) include a reference to the enterprise/site/database. 
To keep the number of primary key columns to a minimum, CRIS V3 combines the enterprise ID (also 4- 
bytes) and the site ID into a fixed-length 16-character MIMOSA site code. This site code is composed of 
these two 4-byte non-negative integers which are converted into their hexadecimal format (resulting in 8 
characters per integer) and then concatenated into a fixed-length 16-character string. 


Version 3 of CCOM & CRIS have also added the ability to build Site templates. Templates are like "models" 
of sites which allows you to predefine characteristics of a Site, including its Segments, which software can 
utilize when instantiating a new Site which matches that template. In addition, they provides for a method of 
standard measurement location identification across various condition monitoring technologies. Trendable, 
scalar data such as operational temperatures, pressures, and loads are modelled in CCOM/CRIS. 
CCOMICRIS support dynamic data, such as time waveforms and Fast Fourier Transforms (FFTs), which are 
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used in vibration analysis and sound monitoring. Binary data, known as Binary Large OBjects or (BLOBs), 
are supported for communicating drawings, reports, diagrams, and photographs. CCOM/CRIS also manages 
sampling test data results, such as used oil analysis test data and air quality monitoring data. CCOM/CRIS 
also allows the communication of diagnostic, health, and prognostic information from smart systems and 
eases the generation of advisory recommendations. Special maintenance and reliability tables define fields 
for events (actual, hypothesized, proposed), health, estimated asset life assessment, and recommendations. 
CCOMI/CRIS model maintenance and production work request scheduling and the tracking of the completion 
(or non-completion) of a maintenance or production job as related to an asset. CCOM/CRIS also provides 
the information framework for storing reliability data for assets. 


CRIS Reference Database Specification 

CCOMICRIS contain many "type" classes/tables, which allow users to associate types of enterprises, sites, 
segments, assets, agents, measurement locations, engineering units, etc. with standard numeric codes, 
common throughout all their various systems. MIMOSA generates and maintains industry-standard 
taxonomies and codes for most of these tables, but CCOM/CRIS allow both suppliers and end-users to add 
industry-specific and customer-specific entries to these tables. MIMOSA experts have generated a large 
reference database, the CRIS Reference Database Specification in XML, and several popular relational 
database formats. Version 3 of this database specification contains many useful codes which allow 
standardization across many disparate systems—even those from various countries. For example, the asset 
type table allows standard querying of common asset types such as “AC induction motor” which have 
unchanging three-integer unique identifiers. Other standard code tables include service segment, 
measurement location, engineering units, sampling test codes, diagnostic/prognostic event codes, health 
codes, failure codes, and root cause codes. This allows systems to search across various systems for 
common failures on certain equipment types. 


Tech-XML Client/Server Interface Schemas 

A key component of MIMOSA’s Open System Architecture for Enterprise Application Integration (OSA-EAI) is 
the Tech-XML Client/Server interface schemas. These XML schemas provide a common set XML-based 
client/server interface definitions for various communication protocols. The Tech-XML interfaces specify the 
contents of a client/server data exchange, but do not specify the physical transport method. 


Tech-Doc Producer/Consumer Interface Schemas 

For XML document-based systems, MIMOSA provides the Tech-Doc Producer/Consumer interface schemas, 
which publish/consume CRIS data from a given technology in an XML document format. Tech-Doc interfaces 
specify the contents of an XML document, but do not specify the physical storage and transport method of the 
produced/consumed document. Tech-Doc Consumer Read-only applications will utilize a Tech-Doc XML 
document, but not change its permanent data storage based on this information. Tech-Doc Consumer Write- 
only applications change their permanent data storage after successful file import. 


Tech-XML and Tech-Doc Technology Types 

Both of these OSA-EAI interface technologies (Tech-XML & Tech-Doc) are further sub-divided into eight (8) 
Technology Types (see Architecture Diagram above). This allows developers to focus on supporting only 
what is relevant to their particular application area, such as vibration analysis or maintenance management. 
The technology types are listed in table A.1 below. 


To refer to the entire set of 8 Application Technology Packages, the italicized prefix "Tech-" is used. Each 
vertical application technology only has certain CRIS tables which are relevant. This allows implementers to 
pair down the entire CRIS specification to only the application-specific tables. To support this, MIMOSA 
publishes the Tech-XML Support Level n CRIS V3.0 Subset Specification for Tech-XML developers and 
the Tech-Doc Support Level n CRIS V3.0 Valid Table Entity Specification for Tech-Doc developers. 
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Table A.1 — OSA-EAI Application Technology Packages 


Technology Description 
Types 

Asset Register | Allows retrieval of "as-designed" segment hierarchical breakdown of facility, 

Management process, and machine systems, along with the "as-installed" asset information. 
Also allows access to name plate and image data on individual assets and models, 
including component part breakdowns. 

(REG) Used by: 
- OEM Model Information Systems 
- Asset Registry Information Systems 
- Maintenance Management Systems 
- Piping & Instrumentation Design Systems 

Work Allows the creation and audit tracking of a new work request in a work management 

Management system for a service segment or a serialized asset. Allows the retrieval of work 
orders and work order steps, and actual work completed information.. Also allows 
the retrieval of pre-planned work packages ("solution packages"). 

(WORK) Used by: 


- Maintenance Management Systems 


Diagnostics / 


Enables retrieval of human or "smart-agent" generated current and/or future 


Health / Rec. proposed asset health states, current and/or future proposed diagnostic failure 
modes and casual trees, remaining useful life predictions, and recommendations. 
Also allows access to measurement evidence supporting the diagnoses/prognoses. 
(DIAG) Used by: 
- Diagnostic Systems 
- Prognostic Systems 
Dynamic Enables the creation and retrieval of historical dynamic measurements (used with 
Vibration / vibration and sound monitoring and including frequency spectra measurements and 
Sound time waveforms), abnormal data alarms, and operational event logs. 
(DYN) Used by: 
- Vibration Condition Monitoring Systems 
- Sound Condition Monitoring Systems 
Static Enables the creation and retrieval of historical scalar measurements, abnormal data 
Trends/Alarms alarms, and operational event logs. 
(TREND) Used by: 


- Process Data Historians 
- Process Condition Monitoring Systems 


- Used by Operational Data Systems 


Oil/Fluid/Gas/So 
lid Tests 


(SAMPLE) 


Enables the creation and retrieval of historical fluid, air, and solid sampling data, 
abnormal data alarms, and operational event logs. 


Used by: 
- Oil Sampling Condition Monitoring Systems 
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Technology Description 


Types 


- Air Sampling Condition Monitoring Systems 


- Solid Sampling Condition Monitoring Systems 


Binary Enables the creation and retrieval of historical binary large objects (BLOB) 
Data/Thermo- measurements (used with thermography and imaging monitoring), abnormal data 
graphy alarms, and operational event logs 

(BLOB) Used by: 


- Thermographic Condition Monitoring Systems 


- Image Monitoring Systems 


Tech-Web Specifications 

The OSA-EAI Tech-Web specifications are used for building a server or a client which can communicate data 
and information between condition monitoring systems, diagnostic systems, reliability management systems, 
registry management systems, and work management systems via HTTP or HTTPS (secure) protocol using 
XML messages. The interfaces are defined using XML Schema and specified in a client/server fashion. 


Tech-Web servers must comply with MIMOSA's Tech-Web Client & Server HTTP Binding Specification 
supporting interfaces defined for a given technology type (TREND, REG, WORK, etc), access type (Read- 
Only, Write-Only, or Read/Write), support level (level 1 or 2), and version level (3.0). 


MIMOSA's OSA-CBM™ CM&D Processing Architecture Specification 


MIMOSA’s Open Systems Architecture for Condition-Based Maintenance (OSA-CBM) specification (available 
for download at www.osacbm.org) is compliant as a CM&D processing architecture specification. In order to 
standardize an architecture for a CBM system, the system must be broken down into generalized components 
or functions. This software architecture has been described in terms of functional layers. Starting with data 
acquisition and progressing towards decision support, the general functions of the layers are specified below. 
Each layer has the capability of requesting data from any functional layer as needed, however data flow will 
usually occur between adjacent functional layers. 


e Layer 1 — Data Acquisition: The data acquisition module has been generalized to represent the 
software module that provides system access to digitized sensor or transducer data. The data 
acquisition module may represent a specialized data acquisition module that has analog feeds from 
legacy sensors, or it may collect and consolidate sensor signals from a data bus. Alternately, it might 
represent the software interface to a smart sensor (e.g. IEEE 1451 compliant sensor). The data 
acquisition module is basically a server of calibrated digitized sensor data records. 


e Layer 2— Data Manipulation: The data manipulation module may perform single and/or multi-channel 
signal transformations along with specialized CBM feature extraction algorithms. 


e Layer 3— State Detection: The primary function of the state detection module is to compare features 
against expected values or operational limits and output enumerated condition indicators (e.g. level 
low, level normal, level high, etc). The state detection module may also generate alerts based on 
defined operational limits. When appropriate data is available, the condition monitor may generate 
assessments of operational context (current operational state or operational environment). 


e Layer 4— Health Assessment: The primary function of the health assessment layer is to determine if 
the health of a monitored system, subsystem, or piece of equipment is degraded. If the health is 
degraded, this layer may generate a diagnostic record that proposes one or more possible fault 
conditions with an associated confidence. The health assessment module should take into account 
trends in the health history, operational status and loading, and the maintenance history. 
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e Layer 5 — Prognostic Assessment: The primary function of the prognostics layer is to project the 
current health state of equipment into the future, taking into account estimates of future usage profiles. 
The prognostics layer may report health status at a future time, or may estimate the remaining useful 
life (RUL) of an asset given its projected usage profile. Assessments of future health or RUL may 
also have an associated diagnosis of the projected fault condition. 


e Layer 6 — Advisory Generation: The primary function of the advisory generation module is to provide 
recommended actions and alternatives and the implications of each recommended action. 
Recommendations include maintenance action schedules, modifying the operational configuration of 
equipment in order to accomplish mission objectives, or modifying mission profiles to allow mission 
completion. The decision support module needs to take into account operational history (including 
usage and maintenance), current and future mission profiles, high-level unit objectives, and resource 
constraints. 


After the specification is defined and developed for each CBM module, the modules can be constructed into a 
complete functional CBM system. Open systems architecture design enables the integration of improved 
prognostic capability within new or existing system designs, allowing maximum flexibility and upgradeability of 
the system. 


OSA-CBM Framework 

The OSA-CBM framework was developed around input from the functional layer descriptions and existing and 
emerging standards for monitoring and maintenance, such as MIMOSA's OSA-EAI Information Schema, Al- 
ESTATE, and IEEE 1451.2. The OSA-CBM framework currently excludes the decision support layer since it 
is application specific. The presentation layer was designed as a client-only layer in order to stay open to any 
user interface technology; no interfaces are therefore defined as part of the standard. The first step was 
defining an object oriented data model in Unified Modeling Language (UML) for each layer that was then 
converted into an abstract interface specification. The abstract specification can then be converted to the 
desired middleware language for a specific interface definition. The components of the OSA-CBM 
development architecture are shown in Figure A.2 below. 


The UML object model defines interfaces only. For a given layer of the architecture, the data model does not 
prescribe the object classes that would be required for a software implementation. The focus is on describing 
the structure of the information that might be of interest to clients of that layer. OSA-CBM does not impose 
any requirements on the internal structure of compliant software modules. The architectural constraints are 
applied to the structure of the public interface and to the behavior of the modules. This approach allows 
complete encapsulation of proprietary algorithms and software design approaches within the software module. 
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Figure A.2 — OSA-CBM Development Architecture 


Once the UML data model was defined for each layer, it was converted into a Pseudo-code language that 
could be ported to concrete interface definition languages. Abstract Interface Definition Language (AIDL) was 
selected as the Pseudo-code language. Using a custom Java program, this AIDL code was then converted 
into an XML Schema. The AIDL file is also used to generate COM/DCOM IDL files and documentation. Note 
that the UML, AIDL, COM/DCOM, OMG CORBA IDL, and XML Schema files are provided for each layer 
(excluding the decision support layer), therefore generation of these files is not necessary by the system 


developer. For a copy of the current open specifications including the UML, AIDL, XML, OMG CORBA IDL, 
and COM/DCOM IDL files, see www.osacbm.org. 
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